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Status of This Memo 
This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 


Copyright (c) 2009 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents in effect on the date of 
publication of this document (http://trustee.ietf.org/license-info). 


Please review these documents carefully, as they describe your rights 


and restrictions with respect to this document. 
Abstract 
This document describes a set of Layer 2 Tunneling Protocol (L2TP) 


Attribute Value Pair (AVP) extensions designed to carry the 
subscriber Access Line identification and characterization 


information that arrives at the Broadband Remote Access Server (BRAS) 
with L2TP Access Concentrator (LAC) functionality. It also describes 


a mechanism to report connection speed changes, after the initial 


connection speeds are sent during session establishment. The primary 


purpose of this document is to provide a reference for DSL equipment 
vendors wishing to interoperate with other vendors’ products. The 
L2TP AVPs defined in this document are applicable to both L2TPv2 and 
L2TPv3. 
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1. Introduction 


Access Nodes (ANs), referred to as Digital Subscriber Line Access 
Multiplexers (DSLAMs) in DSL, are adding enhancement features to 
forward, via in-band signaling, subscriber Access Line identification 
and characterization information to their connected upstream 
Broadband Remote Access Server (BRAS) with L2TP Access Concentrator 
(LAC) functionality. 


The Access Node/DSLAM may forward the information via one or more of 
the following methods: 


o Vendor-Specific Point-to-Point Protocol over Ethernet (PPPoE) Tags 
[RFC2516]. 


o DHCP Relay Options [RFC3046] and Vendor-Specific Information 
Suboptions [RFC4243]. 


o Access Node Control Protocol [ANCP]. 


Currently, this information is been collected on the BRAS and 
forwarded to a radius server via [RFC4679]. 


This document describes the new additional L2TP AVPs that were 
created to forward the subscriber line identification and 
characterization information received at the BRAS/LAC to the 
terminating L2TP Network Server (LNS). It also describes a mechanism 
by which the LAC may report connection speed changes to the LNS, 
after the initial connection speeds are sent by the LAC during 
session establishment. 


The L2TP AVPs defined in this document MAY be used with either an 
L2TPv2 [RFC2661] or L2TPv3 [RFC3931] implementation. 


The information acquired may be used to provide authentication, 
policy, and accounting functionality. It may also be collected and 
used for management and troubleshooting purposes. 


2. Terminology 


The following sections define the usage and meaning of certain 
specialized terms in the context of this document. 


2.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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2.2. Technical Terms and Acronyms 
Access Node/DSLAM 


The Access Node/DSLAM is a DSL signal terminator that contains a 
minimum of one Ethernet or ATM interface that serves as its 
upstream interface into which it aggregates traffic from several 
ATM-based (subscriber ports) or Ethernet-based downstream 
interfaces. 


BNG 


Broadband Network Gateway. A BNG is an IP edge router where 
bandwidth and Quality-of-Service (QoS) policies are applied; the 
functions performed by a BRAS are a superset of those performed by 
a BNG. 


BRAS 


Broadband Remote Access Server. A BRAS is a BNG and is the 
aggregation point for the subscriber traffic. It provides 
aggregation capabilities (e.g., IP, PPP, Ethernet) between the 
access network and the core network. Beyond its aggregation 
function, the BRAS is also an injection point for policy 
management and IP QoS in the access network. 


DSL 


Digital Subscriber Line. DSL is a technology that allows digital 
data transmission over wires in the local telephone network. 


DSLAM 
Digital Subscriber Line Access Multiplexer.  DSLAM is a device 
that terminates DSL subscriber lines. The data is aggregated and 
forwarded to ATM- or Ethernet-based aggregation networks. 

IWF 
Interworking Function. The set of functions required for 
interconnecting two networks of different technologies (e.g., ATM 


and Ethernet).  IWF is utilized to enable the carriage of Point- 
to-Point Protocol over ATM (PPPoA) traffic over PPPOoE. 
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LAC 


L2TP Access Concentrator. If an L2TP Control Connection Endpoint 
(LCCE) is being used to cross-connect an L2TP session directly to 
a data link, we refer to it as an L2TP Access Concentrator (LAC). 
(See [RFC2661] and [RFC3931].) 


LCCE 


L2TP Control Connection Endpoint. An L2TP node that exists at 
either end of an L2TP control connection. May also be referred to 
as an LAC or LNS, depending on whether tunneled frames are 


processed at the data link (LAC) or network layer (LNS). (See 
[RFC3931].) 

LNS 
L2TP Network Server. If a given L2TP session is terminated at the 


L2TP node and the encapsulated network layer (L3) packet processed 
on a virtual interface, we refer to this L2TP node as an L2TP 
Network Server (LNS). (See [RFC2661] and [RFC3931].) 


Access Line Information L2TP AVP Operation 


When the BRAS with LAC functionality receives the Access Line 
information from the Access Node and has determined that the session 
will be established with an LNS, the LAC will forward the information 
that it has collected in the newly defined L2TP AVPs. The LAC will 
only forward the Access Line Information AVPs that have populated 
values. 


Access Line information from any of the above methods must be 
available at the BRAS prior to the start of session negotiation by 
the LAC. This ensures Access Line parameters are reliably provided 
to the LNS and avoids additional call set-up delays. Under the 
condition that the LAC has not received any Access Line information 
from any of the methods, as default behavior the LAC SHOULD establish 
the L2TP session without waiting for the Access Line information. In 
this case, the LAC MUST NOT send any of the Access Line AVPs to the 
LNS. The LAC MAY, as local policy, wait for the Access Line 
information from one or more of the methods before forwarding the 
information in the Access Line L2TP AVPs to the LNS. 


It is possible that the Access Node will only send a subset of the 
currently available line information defined. The LAC MUST be able 
to limit and/or filter which AVPs, if any, are sent to the LNS. 
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It is also possible that the LAC may receive Access Line information 
from multiple sources and at different time intervals. Local policy 
SHOULD determine which source(s) the LAC will accept. The LAC SHOULD 
default to accepting ANCP-sourced parameters. 


The Access Line AVPs are sent as part of the L2TP Incoming-Call- 
Request (ICRQ) control message. Connect Speed Update AVPs are sent 
as part of the Connect-Speed-Update-Notification (CSUN) or Connect- 
Speed-Update-Request (CSURQ) L2TP messages (see Sections 4, 4.1, and 
4.22): 


It is possible for the LAC to send updated Connect Speed 
characteristics to the LNS via the Connect Speed Update AVP in an 
L2TP Connect-Speed-Update-Notification (CSUN) control message (see 
Section 4.1). To avoid unnecessary L2TP Connect-Speed-Update-Request 
and Connect-Speed-Update-Notification message exchanges between the 
LAC and LNS (e.g., during failover protocol recovery and 
resynchronization), the LAC signals in the session establishment 
exchange its ability and desire to provide speed updates during the 
life of the session. This is achieved using a new AVP, Connect Speed 
Update Enable (see Section 6.2), sent in the L2TP Incoming-Call- 
Request (ICRQ) control message. The absence of this AVP in the ICRQ 
message implies that the LAC will not be sending any speed updates 
during the life of the session. If the LAC is configured to accept 
ANCP-sourced parameters, and supports providing speed updates during 
the life of a session, it MUST send the Connect Speed Update Enable 
AVP in the ICRQ, since this implies that speed updates may occur over 
the life of the connection. If the LAC is configured to only accept 
PPPoE vendor-specific tags, it MUST NOT send the Connect Speed Update 
Enable AVP in the ICRQ, since the connection speed is only sent 
during PPPoE discovery and no further updates will occur during the 
life of the connection. 


4. Additional L2TP Messages 


If the Access Line information changes while the session is still 
maintained, connection speed updates MAY be sent from the LAC to the 
LNS via an L2TP Connect-Speed-Update-Notification (CSUN) Message (see 
Section 4.1). A new AVP, Connect Speed Update AVP (see Section 6.1), 
is included in the CSUN message to report connect speed updates for a 
specific session after the initial connection speeds are established 
(i.e., at session establishment via the Tx Connect Speed and Rx 
Connect Speed AVPs, Attribute Types 24 and 38, respectively, for 
L2TPv2 and 74 and 75, respectively, for L2TPv3). The values 
established in the Connect Speed Update AVP (as well as the values 
for the initial Tx/Rx Connect Speeds AVPs) are based on LAC local 
policy. For example, the LAC's local policy may use the Actual-Data- 
Rate-Upstream and Actual-Data-Rate-Downstream as its policy to report 
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connection speed updates. For consistency, the same local policy 
SHOULD equally apply both to the initial connect speeds (conveyed 
during session establishment) and to the (optional) connect speed 
updates (sent after the establishment of the session). The CSUN 
message MAY be sent periodically to the LNS based on local policy and 
may include more than one Connect Speed Update AVP. The bulking of 
more than one Connect Speed Update AVP into the CSUN message serves 
the following purposes: 


o Dampens the rate of changes sent to the LNS when Access Line 
parameter updates are received at a high rate for a given line. 


o Efficiently forwards speed updates when Access Line parameter 
updates are received for many lines at the same time. 


o Supports failover [RFC4951] protocol recovery and 
resynchronization. 


During failover recovery and resynchronization, to ensure the correct 
speeds have been applied to outstanding sessions on each tunnel, the 
LNS MAY issue a Connect-Speed-Update-Request (CSURQ) message (see 
Section 4.2) to the LAC containing one or more Session IDs. In 
response to the CSURQ message, the LAC MUST issue a Connect-Speed- 
Update-Notification (CSUN) message (see Section 4.1) containing a 
Connect Speed Update AVP for each of the Session IDs requested in the 
CSURQ. Note: In the CSUN response to the CSURQ, the LAC MUST NOT 
respond to unknown sessions, or to known sessions for which it did 
not issue a Connect Speed Update Enable AVP in the prior Incoming- 
Call-Request (ICRQ) control message for the session (see Sections 3 
and 6.2). 


This section defines two new Messages that are used with the IETF 
Vendor ID of 0 in the Message Type AVP. 


The following message types will be assigned to these new messages 
(see Section 8.1): 


28: (CSUN) Connect-Speed-Update-Notification 

29: (CSURQ) Connect-Speed-Update-Request 
The Mandatory (M) bit within the Message Type AVP SHOULD be clear 
(i.e., not set) for the CSUN and CSURQ control messages, to allow for 


an L2TP Control Connection Endpoint (LCCE) to maintain the control 
connection if the message type is unknown. 
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4.1.  Connect-Speed-Update-Notification (CSUN) 


The Connect-Speed-Update-Notification (CSUN) is an L2TP control 
message sent by the LAC to the LNS to provide transmit and receive 
connection speed updates for one or more sessions. The connection 
Speed may change at any time during the life of the call; thus, the 
LNS SHOULD be able to update its connection speed on an active 
session. 


The following AVPs MUST be present in the CSUN: 
Message Type 
Connect Speed Update (more than one may be present in the CSUN) 


Note that the LAC MUST NOT include a Connect Speed Update AVP for 
which it did not send a Connect Speed Update Enable AVP in the prior 
Incoming-Call-Request (ICRQ) control message for the session. 


4.2.  Connect-Speed-Update-Request (CSURQ) 


The Connect-Speed-Update-Request (CSURQ) is an L2TP control message 
sent by the LNS to the LAC to request the current transmit and 
receive connection speed for one or more sessions. It MAY be issued 
at any time during the life of the tunnel and MUST only be issued for 
each outstanding session on each tunnel on which the LNS has already 
received a Connect Speed Update Enable AVP in the prior Incoming- 
Call-Request (ICRQ) control message for the session. It is typically 
used as part of failover recovery and resynchronization to allow the 
LNS to verify it has the correct speeds for each outstanding session 
on each tunnel. 


The following AVPs MUST be present in the CSURO: 

Message Type 

Connect Speed Update (more than one may be present in the CSURQ) 
The Current Tx Connect Speed and Current Rx Connect Speed fields in 


the Connect Speed Update AVP MUST be set to 0 when this AVP is used 
in the CSURQ message. 


In the CSUN response to the CSURQ, the LAC MUST NOT respond to 
unknown sessions or to known sessions for which it did not issue a 
Connect Speed Update Enable AVP in the prior Incoming-Call-Request 
(ICRQ) control message for the session. 
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Access Line Information L2TP Attribute Value Pair Extensions 


The Access Line information was initially defined in the DSL Forum 
Technical Report TR-101 [TR-101]. TR-101 defines the line 
characteristic that are sent from an Access Node. 


The following sections contain a list of the Access Line Information 
L2TP AVPs. Included with each of the listed AVPs is a short 
description of the purpose of the AVPs. 


The AVPs follow the standard method of encoding AVPs as follows: 
0 1 2 3 


Q0 12.3 45.6 78 9. 01 2.34.56 17.8&.9 0 1 234 5.6 7 8.9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


|M|H| rsvd | Length | Vendor ID 
t—+-+-4+-+4+-4+-4+-4+-4+-4+-4-4+-4+-4-4-4+-4t-4-4-4t-4+-4-4+-4+-4-4-4+-4+-4-4+-4-4-4+ 
| Attribute Type |Attribute Value, if Required 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
(Until Length is reached) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The M bit for all the AVPs defined in this document SHOULD be set to 
0 to allow for backwards compatibility with LNSs that do not support 
the Access Line Information AVP extensions hereby defined. However, 
if it is desired to prevent the establishment of the L2TP session if 
the peer LNS does not support the Access Line Information AVP 
extensions, the M bit MAY be set to 1. See Section 4.2 of [RFC2661] 
and Section 5.2 of [RFC3931]. 


All the AVPs defined in this document MAY be hidden (the H bit MAY be 
0 or 1). 


The Length (before hiding) of all the listed AVPs is 6 plus the 
length of the Attribute Value, if one is required, in octets. 


The Vendor ID for all the listed AVPs (Sections 5.1 through 5.19) is 
that of the IANA assigned ADSL Forum Vendor ID, decimal 3561 
[IANA.enterprise-numbers]. 


All the listed AVPs (Section 5.1 through Section 5.19) MAY be present 
in the following messages unless otherwise stipulated: 


Incoming-Call-Request (ICRQ) 


The Value of the AVP contains information about the Access Line to 
which the subscriber is attached. 
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With the exception of the Connect Speed Update AVP (see Section 6.1), 
all new AVPs specifying a data rate or speed expressed in bits per 
second (bps) will be sent as 64-bits to provide extensibility to 
support future increases in subscriber connection speeds. These new 
AVPs that specify a 64-bit "Data-Rate" are defined from Section 5.3 
to Section 5.12, both inclusive. Whenever a speed value sent in an 
AVP fits within 32 bits, the upper 32 bits MUST be transmitted as Os. 


The various Data-Rates and Interleaving-Delays used in the subsequent 
Sections 5.3 through 5.16 are defined in Section 3.9.4 of [TR-101]. 
The qualifiers used with these Data-Rates and Interleaving-Delays 
have the following meanings: 


o Actual Actual rate or delay of an access loop 
o Attainable Maximum value that can be achieved by the equipment 
o Minimum Minimum value configured by the operator 
o Maximum Maximum value configured by the operator 

5.1. Access Line Agent-Circuit-Id AVP 
The Access Line Agent-Circuit-Id AVP, Attribute Type 1, contains 
information describing the subscriber agent circuit ID corresponding 
to the logical access loop port of the Access Node/DSLAM from which a 
subscriber's requests are initiated. 
The Attribute Value field for this AVP has the following format: 

0 il 2 3 
01234567890123456789012345678090 m1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Agent-Circuit-Id ... (2 to 63 octets) 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Agent-Circuit-Id is of arbitrary length, but MUST be greater than 
1 octet and not greater than 63 octets. 


The Length (before hiding) of this AVP is 6 plus the length of the 
Agent-Circuit-Id. 


The Agent-Circuit-Id contains information about the Access Node/DSLAM 


to which the subscriber is attached, along with a unique identifier 
for the subscriber's DSL port on that Access Node/DSLAM. The Agent- 
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Circuit-Id contains a locally administered string representing the 
access loop logical port, and its syntax is defined in Section 3.9.3 
of [TR-101]. The text string is encoded in the UTF-8 charset 
[RFC3629]. 


An exemplary description of the Agent-Circuit-Id string format 
follows for background purposes. The LAC MUST treat the string as an 
opaque value and MUST NOT manipulate or enforce the format of the 
string based on the description here or in TR-101 [TR-101]. 


Default syntax for the string is defined in [TR-101]. The examples 
in this section are included only for illustrative purposes. The 
exact syntax of the string is implementation dependent; however, a 
typical practice is to subdivide it into two or more space-separated 
components, one to identify the Access Node and another the 
subscriber line on that node, with perhaps an indication of whether 
that line is Ethernet or ATM. Example formats for this string are 
shown below. 


"Access-Node-Identifier atm slot/port:vpi.vci" 
(when ATM/DSL is used) 


"Access-Node-Identifier eth slot/port[:vlan-id]" 
(when Ethernet/DSL is used) 


The syntax for the string is defined in [TR-101]. An example showing 
the slot and port field encoding is given below: 


"Relay-identifier atm 3/0:100.33" 
(slot = 3, port = 0, vpi = 100, vci = 33) 


The Access-Node-Identifier is a unique ASCII string that does not 
include 'space' characters. The syntax of the slot and port fields 
reflects typical practices currently in place. The slot identifier 
does not exceed 6 characters in length, and the port identifier does 
not exceed 3 characters in length using a '/' as a delimiter. 


The exact manner in which slots are identified is Access Node/DSLAM 
implementation dependent. The vpi, vci, and vlan-id fields (when 
applicable) are related to a given access loop (U-interface). 


5.2. Access Line Agent-Remote-Id AVP 
The Access Line Agent-Remote-Id AVP, Attribute Type 2, contains an 
operator-specific, statically configured string that uniquely 


identifies the subscriber on the associated access loop of the Access 
Node/DSLAM. 
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The Attribute Value field for this AVP has the following format: 


0 jT 2 3 

0. 1-2 3:4 5.6 Y '8 9.0.1 2.3 4-5 6:7 8 9.0 1 2,34 5.6.7 8. 9.0. 1 
V—R—R—R-R---—----—R—R-—4——---.-—L-.-.—4——---.-— 4 
| Agent-Remote-Id ... (2 to 63 octets) 
V——R—R-R-R—-—----—R—L- 9-4 ——---.-—.-*.-.—4——---.-— A ++ 


The Agent-Remote-Id is of arbitrary length, but MUST be greater than 
1 octet and not greater than 63 octets. 


The Length (before hiding) of this AVP is 6 plus the length of the 
Agent-Remote-Id. 


The Agent-Remote-Id contains information sent from the Access Node/ 
DSLAM from which the subscriber is attached, to further refine the 
access loop logical port identification with a user. The content of 
this message is entirely open to the service provider's discretion. 
For example, it MAY contain a subscriber billing ID or telephone 
number. The LAC MUST treat the string as an opaque value and MUST 
NOT manipulate or enforce its format. The text string is defined in 
[TR-101], and is encoded in the UTF-8 charset [RFC3629]. 


5.3. Access Line Actual-Data-Rate-Upstream AVP 


The Access Line Actual-Data-Rate-Upstream AVP, Attribute Type 129, 
contains the actual upstream train rate of a subscriber's 
synchronized Access link. 


The Attribute Value field for this AVP has the following format: 


0 1 2 3 
Q0. I:2-3-4 50:6,77 8: 9 Q. 1 2:534 5.0. 4:8 Oe 12 3-4 .5-6.7 8 9 0: T 
tapo cies ae Cie cl ae ee abad da lo dll a do Ss a et os ee ee > 
| Actual-Data-Rate-Upstream 
HA AO AO O + BM BM BM BAÁ BM BÀ BMÁBMBGBRBRMBMBLMÁBMBMÁÁBMÁ MM MM + + + ++ 
in bps (64 bits) 
++ AO AO O + B BM M BM BAM BM BMBMÁBMÁBMBMBMGBMGÁB—M BM M -t + + 


The Actual-Data-Rate-Upstream is an 8-octet value. 
The Actual-Data-Rate-Upstream AVP contains an 8-octet unsigned 
integer, indicating the subscriber's actual data rate upstream of a 


synchronized Access link. The rate is coded in bits per second. 


The Length (before hiding) of this AVP is 14. 
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5.4. Access Line Actual-Data-Rate-Downstream AVP 


The Access Line Actual-Data-Rate-Downstream AVP, Attribute Type 130, 
contains the actual downstream train rate of a subscriber's 
synchronized Access link. 


The Attribute Value field for this AVP has the following format: 


0 1 2 3 
01234567829 0123456789012345678901 
HR Ah dd + dd + dd + dd + dd +++ ++ ++ BM ++ +++ 

| Actual-Data-Rate-Downstream 

PR dh dd — + dd + dd + dd + $ 4 +++ +++ +++ +++ +++ 
in bps (64 bits) | 

PR A + dd + dd — + — dd + dd + dd +++ +++ +++ +++ +++ 


The Actual-Data-Rate-Downstream AVP contains an 8-octet unsigned 
integer, indicating the subscriber's actual data rate downstream of a 
synchronized Access link. The rate is coded in bits per second. 


The Length (before hiding) of this AVP is 14. 
5.5. Access Line Minimum-Data-Rate-Upstream AVP 


The Access Line Minimum-Data-Rate-Upstream AVP, Attribute Type 131, 
contains the subscriber's operator-configured minimum upstream data 
rate. 


The Attribute Value field for this AVP has the following format: 


0 t 2 3 
0123456789 0123456789012345678901 
PA A A A A A A A A A A A A A A A A A A A A e A o o git 

| Minimum-Data-Rate-Upstream 

(——————R——————^—A—A^A^AA^A^——^A4—^A4^AA^A^—^—4^—^5R^A——————— 2 
in bps (64 bits) | 

(€——————————————————^^A—A——^A^A^A4^4^AW^—4————^^—€—^A^ARA^————»————————— it 


The Minimum-Data-Rate-Upstream AVP contains an 8-octet unsigned 
integer, indicating the subscriber's minimum upstream data rate (as 


configured by the operator). The rate is coded in bits per second. 


The Length (before hiding) of this AVP is 14. 
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5.6. Access Line Minimum-Data-Rate-Downstream AVP 


The Access Line Minimum-Data-Rate-Downstream AVP, Attribute Type 132, 
contains the subscriber's operator-configured minimum downstream data 
rate. 


The Attribute Value field for this AVP has the following format: 


0 il: 2 3 
012345647289012345678°901234567890 1 
Po no II HHHH 

| Minimum-Data-Rate-Downstream 

———————————————————————————————————————————— 
in bps (64 bits) | 

————^————————————————————————————————————————— 


The Minimum-Data-Rate-Downstream AVP contains an 8-octet unsigned 
integer, indicating the subscriber's minimum downstream data rate (as 
configured by the operator). The rate is coded in bits per second. 


The Length (before hiding) of this AVP is 14. 
5.7. Access Line Attainable-Data-Rate-Upstream AVP 


The Access Line Attainable-Data-Rate-Upstream AVP, Attribute Type 
133, contains the subscriber's actual attainable upstream data rate. 


The Attribute Value field for this AVP has the following format: 


0 1 2 3 
0.1.2834 5 OF 8.9 0 $T 2.3.4 5.6 7.8 9 01 2 345 6 7.8 9 0 f 
tata tata tata tata tata ta tata ta tata + q + ++ +++ +++ +++ +++ 

| Attainable-Data-Rate-Upstream 

PR A A O O + e + e + $ + + + + d+ + ++ +++ +++ +++ +++ 
in bps (64 bits) | 

tata A tata tata ta tata ta tata tata + ta tata ++ +++ +++ +++ +++ 


The Attainable-Data-Rate-Upstream AVP contains an 8-octet unsigned 
integer, indicating the subscriber's Access Line actual attainable 
upstream data rate. The rate is coded in bits per second. 
The Length (before hiding) of this AVP is 14. 

5.8. Access Line Attainable-Data-Rate-Downstream AVP 
The Access Line Attainable-Data-Rate-Downstream AVP, Attribute Type 


134, contains the subscriber's actual attainable downstream data 
rate. 
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The Attribute Value field for this AVP has the following format: 


0 T 2 3 
0-1-2 X4 5.6 7'8 9.0.1 23 4.5» 6:7 8 9.0 1 2,34 5.6 7:8 9.0. 1 
*—4—4—4-—4-4-t-t-t-t----*-t-t-t-—t-—t—L-—L—4— ——4—4—4-4-4-4-4-4-4 

| Attainable-Data-Rate-Downstream 

Fatt tata tata tar a o o o E O 
in bps (64 bits) | 

*—4—4—4—4-—4-t-t-t-t----t-t-t-t-t-t—L-— 4-4 ——4—4-4-4-4-4-4-4-4 


The Attainable-Data-Rate-Downstream AVP contains an 8-octet unsigned 
integer, indicating the subscriber's Access Line actual DSL 
attainable downstream data rate. The rate is coded in bits per 
second. 


The Length (before hiding) of this AVP is 14. 
5.9. Access Line Maximum-Data-Rate-Upstream AVP 


The Access Line Maximum-Data-Rate-Upstream AVP, Attribute Type 135, 
contains the subscriber's maximum upstream data rate, as configured 
by the operator. 


The Attribute Value field for this AVP has the following format: 


0 1 2 3 
012 3.4.5678 901.2 3 45 678 9012 34.506 78 9 0 1 
(—————————————————AA—^———————————— A ——— H 

| Maximum-Data-Rate-Upstream 

——————R—————————————A—AAA————————— gt 
in bps (64 bits) | 

——————R————————————ORR——————— —— 


The Maximum-Data-Rate-Upstream AVP contains an 8-octet unsigned 
integer, indicating the numeric value of the subscriber's Access Line 
maximum upstream data rate. The rate is coded in bits per second. 
The Length (before hiding) of this AVP is 14. 

5.10. Access Line Maximum-Data-Rate-Downstream AVP 
The Access Line Maximum-Data-Rate-Downstream AVP, Attribute Type 136, 


contains the subscriber's maximum downstream data rate, as configured 
by the operator. 
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The Attribute Value field for this AVP has the following format: 


0 1 2 3 
Q.T-2 3 4 5 6 T7 8 9.0.1 2.3 4.5 6.7.8 9 0 1 2. 3 4 5.6 7-8 90: 1 
————————————————————————————————————————————— 

| Maximum-Data-Rate-Downstream 

———————————————————————————————————————— t 
in bps (64 bits) | 

———^————————————————————————————————————— 


The Maximum-Data-Rate-Downstream AVP contains an 8-octet unsigned 
integer, indicating the numeric value of the subscriber's Access Line 
maximum downstream data rate. The rate is coded in bits per second. 


The Length (before hiding) of this AVP is 14. 
5.11. Access Line Minimum-Data-Rate-Upstream-Low-Power AVP 


The Access Line Minimum-Data-Rate-Upstream-Low-Power AVP, Attribute 
Type 137, contains the subscriber's minimum upstream data rate in low 
power state, as configured by the operator. 


The Attribute Value field for this AVP has the following format: 


0 1 2 3 
0- 1-22 4 5 6 7&9 0. 1 2.3 4 5 6 T 8.9 0.1 2.3.4 5.6 T 9 9.0. 1 
T—R—4—4—4-—4-t-t-t-t----*-t-t-t-t-—L-—L-— -4— ——4—4—4-4-4-4-4-4-4 
| Minimum-Data-Rate-Upstream-Low-Power 
Fatt rt ata tata a tanta tata tata tt atta tata ———4—4-4-4-4-4-4-4 
in bps (64 bits) 
Fatt tata tata a a t arta t ata tanta tata t tata -— 4 ———4-4-4-4-4-4-4-4 


The Minimum-Data-Rate-Upstream-Low-Power AVP contains an 8-octet 
unsigned integer, indicating the numeric value of the subscriber's 
Access Line minimum upstream data rate when in low power state 
(L1/L2). The rate is coded in bits per second. 
The Length (before hiding) of this AVP is 14. 

5.12. Access Line Minimum-Data-Rate-Downstream-Low-Power AVP 
The Access Line Minimum-Data-Rate-Downstream-Low-Power AVP, Attribute 


Type 138, contains the subscriber's minimum downstream data rate in 
low power state, as configured by the operator. 
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The Attribute Value field for this AVP has the following format: 


0 1 2 3 
0- I-22 3:4 5 6 78 9.0.12.3 4.5 6/7 8 9 012 4 5.6 7.8.9.0. 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Minimum-Data-Rate-Downstream-Low-Power 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
in bps (64 bits) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Minimum-Data-Rate-Downstream-Low-Power AVP contains an 8-octet 
unsigned integer, indicating the numeric value of the subscriber’s 
Access Line minimum downstream data rate when in low power state 
(L1/L2). The rate is coded in bits per second. 


The Length (before hiding) of this AVP is 14. 
5.13. Access Line Maximum-Interleaving-Delay-Upstream AVP 
The Access Line Maximum-Interleaving-Delay-Upstream AVP, Attribute 
Type 139, contains the subscriber's maximum one-way upstream 
interleaving delay, as configured by the operator. 
The Attribute Value field for this AVP has the following format: 
0 1 2 3 
01234567829 01234567829012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Maximum-Interleaving-Delay-Upstream 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
The Maximum-Interleaving-Delay-Upstream AVP contains a 4-octet 
unsigned integer, indicating the numeric value in milliseconds of the 
subscriber's Access Line maximum one-way upstream interleaving delay. 
The Length (before hiding) of this AVP is 10. 
5.14. Access Line Actual-Interleaving-Delay-Upstream AVP 
The Access Line Actual-Interleaving-Delay-Upstream AVP, Attribute 


Type 140, contains the subscriber's actual one-way upstream 
interleaving delay. 
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The Attribute Value field for this AVP has the following format: 


0 1 2 3 

0- 1-2 3:4 5. 6 7'8 9.0.1 2.3 4.5 6:7 8 9 0 12,5». 5.6 7-8 .9 0-1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Actual-Interleaving-Delay-Upstream 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Actual-Interleaving-Delay-Upstream AVP contains a 4-octet 
unsigned integer, indicating the numeric value in milliseconds of the 
subscriber's Access Line actual upstream interleaving delay. 


The Length (before hiding) of this AVP is 10. 
5.15. Access Line Maximum-Interleaving-Delay-Downstream AVP 


The Access Line Maximum-Interleaving-Delay-Downstream AVP, Attribute 
Type 141, contains the subscriber's maximum one-way downstream 
interleaving delay, as configured by the operator. 


The Attribute Value field for this AVP has the following format: 


0 1 2 3 
01234567829 0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Maximum-Interleaving-Delay-Downstream 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Maximum-Interleaving-Delay-Downstream AVP contains a 4-octet 
unsigned integer, indicating the numeric value in milliseconds of the 
subscriber's Access Line maximum one-way downstream interleaving 
delay. 
The Length (before hiding) of this AVP is 10. 

5.16. Access Line Actual-Interleaving-Delay-Downstream AVP 
The Access Line Actual-Interleaving-Delay-Downstream AVP, Attribute 


Type 142, contains the subscriber's actual one-way downstream 
interleaving delay. 
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The Attribute Value field for this AVP has the following format: 


0 jT 2 3 
0.12 X4 5.6 7 '8& 9.0.1 2.3 45 6:78 9 0 1 2.3 4 5. 6 7.8.9.0. 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Actual-Interleaving-Delay-Downstream 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Actual-Interleaving-Delay-Downstream AVP contains a 4-octet 
unsigned integer, indicating the numeric value in milliseconds of the 
subscriber’s Access Line actual downstream interleaving delay. 

The Length (before hiding) of this AVP is 10. 


5.17. Access Line Access-Loop-Encapsulation AVP 


The Access Line Access-Loop-Encapsulation AVP, Attribute Type 144, 
describes the encapsulation(s) used by the subscriber on the access 
loop. 


The Length (before hiding) of this AVP is 9. 

The Access-Loop-Encapsulation value is comprised of three l-octet 
values representing the Data Link, Encapsulation 1, and Encapsulation 
2, respectively. 

The Access-Loop-Encapsulation value is 3 octets in length, logically 


divided into three l-octet sub-fields, each containing its own 
enumeration value, as shown in the following diagram: 


0 1 2 
0123456789 01234567890123 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Data Link | Encaps 1 | Encaps 2 | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Valid values for the sub-fields are as follows: 
Data Link 
0x00 ATM AAL5 


0x01 Ethernet 
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NA - Not Available 


Untagged Ethernet 


0x02 Single-Tagged Ethernet 


Encaps 2 


0x00 


0x01 


0x02 


0x03 


0x04 


0x05 


0x06 


0x07 


0x08 


NA - Not Available 


PPPoA LLC 


PPPoA Null 


IP over ATM (IPOA) 


IPoA Null 


Ethernet over AAL5 


Ethernet over AAL5 


Ethernet over AAL5 


Ethernet over AAL5 


5.18. ANCP Access Line Type AVP 


The ANCP Access Line Type AVP, 


LLC 


LLC with Frame Check Sequence (FCS) 
LLC without FCS 
Null with FCS 


Null without FCS 


Attribute Type 145, describes the 


transmission systems on access loop to the subscriber. 


The Attribute Value field for this AVP has the following format: 


0 


T 


2 3 


0-1-223-4 5-6 T 8.9 0.1.2 -3 4-576^:7.8 9 0 1.2.3.4 5 6 7T & 9-0. 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


ANCP- 


Access-Line-Type | 


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Length 


(before hiding) of 


this AVP is 10. The ANCP Access Line 


Type AVP defines the type of transmission system used. 
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The ANCP Access Line Type AVP contains a l-octet field encoding the 
Transmission System, followed by a 3-octet reserved field (MUST be 
zero), and is 4 octets in length. It indicates the transmission 
systems on access loop to the subscriber. The current valid values 
only utilize the 1-octet field. 
Valid values are as follows: 
Transmission system: 

0x01 ADSL1 

0x02 ADSL2 

0x03 ADSL2+ 

0x04 VDSL1 


0x05 VDSL2 


0x06 SDSL 


0x07 UNKNOWN 
5.19. Access Line IWF-Session AVP 
The Access Line IWF-Session AVP, Attribute Type 254, indicates if an 
Interworking Function has been performed with respect to the 
subscriber’s session. 
The Attribute Value field for this AVP has the following format: 
0 1 2 3 
0123456789 0123456789012345678901 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Inter-Working Function 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
The Inter-Working Function is a 4-octet value. 
Valid values for this field are as follows: 
0x00 IWF not performed 


0x01 IWF performed 


The Length (before hiding) of this AVP is 10. 
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6. Connect Speed Update L2TP Attribute Value Pair Extensions 


The following sections define Connect Speed Update related AVPs. 
These AVPs (Section 6.1 and Section 6.2) use the IETF Vendor ID of 0. 


The M bit for these AVPs SHOULD be set to 0. However, if it is 
desired to prevent the establishment or tear down the established 
L2TP session if the peer LNS does not support the Connect Speed 
Update AVP extensions, the M bit MAY be set to 1. See Section 4.2 of 
[RFC2661] and Section 5.2 of [RFC3931]. 


6.1. Connect Speed Update AVP (CSUN, CSURQ) 


The Connect Speed Update AVP, Attribute Type 97, contains the updated 
connection speeds for this session. The format is consistent with 
that of the Tx Connect Speed and Rx Connect Speed AVPs for L2TPv2 
(Attribute Types 24 and 38, respectively) and L2TPv3 (Attribute Types 
74 and 75, respectively). Hence, there is a separate format defined 
for L2TPv2 and L2TPv3. 


The Attribute Value field for this AVP has the following format for 
L2TPv2 Tunnels: 


0 1 2 3 
012345678901234567890123456780901 
a a o o o o O 

| Reserved | Remote Session Id 
T—4—4—4-—4-4-t-t-t-t----t-t-t-t-t-—t-—tL-— — 4 —4—4—4—4-4-4-4-4-4-4 
| Current Tx Connect Speed in bps 

FPP tata tata tartar a a o o o E 
| Current Rx Connect Speed in bps 

Fatt ta tata ta EA a o o o A 
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The Attribute Value field for this AVP has the following format for 
L2TPv3 Tunnels: 


0 1: 2 3 
0.1.22 394 Oy 6. PF 8-9.0 1 2 3.4 5.6 7 89 0.12 34 5-6 7 8 9.0 T 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 

| Remote Session Id 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
| Current Tx Connect Speed in bps... 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
...Current Tx Connect Speed in bps (64 bits) 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
Current Rx Connect Speed in bps... 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
...Current Rx Connect Speed in bps (64 bits) | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Remote Session Id is the remote session id relative to the sender 
(i.e., the identifier that was assigned to this session by the peer). 
The Current Tx Connect Speed is a 4-octet value (L2TPv2) or an 
8-octet value (L2TPv3) representing the current transmit connect 
Speed, from the perspective of the LAC (e.g., data flowing from the 
LAC to the remote system). The rate is encoded in bits per second. 
The Current Rx Connect Speed is a 4-octet value (L2TPv2) or an 
8-octet value (L2TPv3) representing the current receive connect 
Speed, from the perspective of the LAC (e.g., data flowing from the 
remote system to the LAC). The rate is encoded in bits per second. 


The Length (before hiding) of this AVP is 18 (L2TPv2) or 26 (L2TPv3). 
6.2. Connect Speed Update Enable AVP (ICRQ) 


The Connect Speed Update Enable AVP, Attribute Type 98, indicates 
whether the LAC intends to send speed updates to the LNS during the 
life of the session. The Connect Speed Update Enable AVP is a 
boolean AVP. Presence of this AVP indicates that the LAC MAY send 
speed updates using CSUN (see Section 4.1) during the life of the 
session, and the LNS SHOULD query for the current connection speed 
via the CSURQ (see Section 4.2) during failover synchronization. 
Absence of this AVP indicates that the LAC will not be sending speed 
updates using CSUN (see Section 4.1) during the life of the session, 
and the LNS MUST NOT query for the current connection speed via the 
CSURQ (see Section 4.2) during failover synchronization. 


The Length (before hiding) of this AVP is 6. 
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7. Access Line Information AVP Mapping 
The Access Line information that is obtained from the Access Node/ 
DSLAM is required to be mapped into the Access Line AVPs. The Access 
Line information can be obtained via: 


o Vendor-Specific PPPoE Tags [RFC2516]. 


o DHCP Relay Options [RFC3046] and Vendor-Specific Information 
Suboptions [RFC4243]. 


o ANCP [ANCP]. 
7.1. Summary of Access Line AVPs 


Table 1 summarizes the Access Line AVPs defined in Sections 5.1 
through 5.19. 


+----------------- 4---------------------------------------- 4 
| Access Line AVP | Name 
4----------------- 4---------------------------------------- 4 
1 (0x01) Agent-Circuit-Id 
2 (0x02) Agent-Remote-Id 

| 129 (0x81) | Actual-Data-Rate-Upstream 
| 130 (0x82) | Actual-Data-Rate-Downstream 
| 131 (0x83) | Minimum-Data-Rate-Upstream 
| 132 (0x84) | Minimum-Data-Rate-Downstream 

133 (0x85) | Attainable-Data-Rate-Upstream | 
| 134 (0x86) Attainable-Data-Rate-Downstream 
| 135 (0x87) | Maximum-Data-Rate-Upstream 
| 136 (0x88) | Maximum-Data-Rate-Downstream 
| 137 (0x89) | Minimum-Data-Rate-Upstream-Low-Power | 
| 138 (0x8A) | Minimum-Data-Rate-Downstream-Low-Power | 

139 (0x8B) Maximum-Interleaving-Delay-Upstream | 
| 140 (0x8C) Actual-Interleaving-Delay-Upstream 
| 141 (0x8D) | Maximum-Interleaving-Delay-Downstream | 
| 142 (0x8E) | Actual-Interleaving-Delay-Downstream | 
| 144 (0x90) | Access-Loop-Encapsulation 
| 145 (0x91) | ANCP Access Line Type 
| 254 (OxFE) | IWF-Session | 
+----------------- 4---------------------------------------- + 


Table 1: Access Line AVP Summary 
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8. IANA Considerations 
Sections 8.1 and 8.2 describe request for new values in 
[IANA.12tp-parameters], for registries already managed by IANA 
assignable through Expert Review according to [RFC3438]. Section 8.3 
describes number spaces not managed by IANA. 
8.1. Message Type AVP Values 
This number space is managed by IANA as per [RFC3438]. There are two 
new message types, defined in Sections 4.1 and 4.2, to be allocated 
for this specification. 
Message Type AVP (Attribute Type 0) Values 
28: (CSUN) Connect-Speed-Update-Notification 
29: (CSURQ) Connect-Speed-Update-Request 


8.2. Control Message Attribute Value Pairs (AVPs) 


This number space is managed by IANA as per [RFC3438]. There are two 
new AVPs, defined in Sections 6.1 and 6.2, to be allocated for this 
Specification. 


Control Message Attribute Value Pairs (AVPs) 
97: Connect Speed Update AVP 
98: Connect Speed Update Enable AVP 
8.3. Values for Access Line Information AVPs 
The Access Line Information AVPs use the Vendor ID of 3561 for the 
ADSL Forum (now Broadband Forum). The number spaces in these Values 
and their new allocations (e.g., enumerated values for the Access 


Line Access-Loop-Encapsulation AVP and ANCP Access Line Type AVP) are 
managed by the Broadband Forum. 


9. Security Considerations 


The security of these AVP relies on an implied trust relationship 
between the Access Node/DSLAM and the BRAS/LAC, and between the LAC 
and the LNS. The identifiers that are inserted by the Access Node/ 
DSLAM are unconditionally trusted; the BRAS does not perform any 
validity check on the information received before forwarding the 
information. 
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These AVPs are intended to be used in environments in which the 
network infrastructure (the Access Node/DSLAM, the BRAS/LAC, the LNS, 
and the entire network in which those devices reside) is trusted and 
secure. 


Careful consideration should be given to the potential security 
vulnerabilities that are present in this model before deploying this 
option in actual networks. 


The AVPs described in this document are used to carry identification 
and characterization of subscriber Access Line, and to report 
connection speed changes. If used in a non-secure environment, they 
could reveal such information. The Tunnel (Control Connection) 
security considerations are covered in Section 9.1 of [RFC2661] and 
Section 8.1 of [RFC3931]. Additionally, the hiding of AVP attribute 
values mechanism can be used to hide the value of the AVPs described 
in this document, if they are deemed sensitive in some environments. 
AVP hiding is described in Section 4.3 of [RFC2661] and Section 5.3 
of [RFC3931]. 


The Attributes described in this document neither increase nor 
decrease the security of the L2TP protocol. 


It is possible to utilize [RFC3193] "Securing L2TP with IPsec" to 
increase the security by utilizing IPsec to provide for tunnel 
authentication, privacy protection, integrity checking and replay 
protection. 
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